SPA用に Amazon Cognitoユーザープール の設定と OIDC を連携させる手順

こんにちは、ちゃだいんです。

今回は、Amazon Cognitoユーザープール とOIDC を連携させる手順を作成する機会がありましたので、その内容をご紹介します。

基本的には、公式ドキュメントを参考に進めます。
Amazon Cognito ユーザープール - Amazon Cognito

前提

今回進める上で、以下のような前提とします。

• ウェブアプリは Single Page Application (SPA)
• 開発環境で使用するサービスのドメインはdev.example.comとする
• ローカル環境で実行していて、そこから認証を行いたい
• その他のリソースは構築済み

手順

1.Cognitoユーザープールを作成する

ユーザープール名を決めます。
今回はproject-dev-userpoolと入力します。

一般的なEメールアドレスを「ユーザー名」として使用してサインアップ・サインインする方式を選びます。
メールアドレスは大文字・小文字を区別しないものが一般的かと思われるのでデフォルト有効の推奨設定はそのままでいきます。
アプリ側の要件に応じて「標準属性の必須」有無を選択しますが、今回は特になしとして進めます。
※本画面の「カスタム属性の追加」以外は、後で変更できないのでご注意ください。

パスワードの強度はデフォルトで進めます。
ユーザーが自分でサインアップできるようにしたいので、「ユーザーに自己サインアップを許可する」にします。

必要に応じて、他要素認証(MFA)でセキュリティを強化できますが、今回はオフにします。
一般的であるパスワードを忘れた場合は確認済みのメールを使用して回復する方式をとります。
これらのメールをCognitoが配信できるように、IAMロールを作成します。

Eメールアドレスをカスタマイズできます。本番環境で使用する場合は、ユーザー側が何のメールなのか理解できるように、SES を連携させ独自ドメインで配信することが推奨されます。
今回はデフォルトの設定（Cognitoから配信）で進めます。
（ちなみに、デフォルト設定だとサインイン時のメールアドレス確認は From:no-reply@verificationemail.com 件名:Your verification code 本文：Your confirmation code is 123456 といった具合で届きます。）

タグは特に設定せずに進めます。

ユーザーのデバイスは記憶しないで進めます。

アプリクライアント（Cognitoの認証を利用するアプリ単位で設定するもの）は新たに作成します。
この設定はアプリ側が何者かによって設定内容が異なります。今回はSPAを想定で進めます。
トークンの有効期限は最小単位の1日で設定します。
アプリクライアントがウェブサーバーなどの場合はクライアントシークレットを使用できますが、SPAの場合は使用しないことが推奨されるのでチェックを外します。
他認証フロー部分では、最低限更新トークンが使用できるように、「更新トークンベースの認証を有効にする」のみチェックをして完了します。

Lambdaを使用してワークフローをカスタマイズすることができますが、今回は使用しません。

最後に全体の確認を行い、ユーザープール作成を完了させてます。

2. Cognito ドメインを設定する

Cognitoのドメインを設定します。

ユーザープールのドメインを設定する - Amazon Cognito

デフォルトドメイン example.auth-<REGION>.amazoncognito.com と所有している独自ドメインから選べますが、今回は独自ドメインを選びます。推奨内容として、SPA側のドメインdev.example.com のサブドメインとしてauthを頭に追加したauth.dev.example.comと入力します。

独自ドメインを使用する場合は、バージニアリージョンにACM証明書が必要となるので、事前に作成しておく必要があります。

今回は事前に設定予定のCognito用ドメインauth.dev.example.comをカバーする*.dev.example.comのワイルドカード証明書を発行してましたので、それを選択し、保存します。

問題ない場合は、ドメインのステータスが作成中になり、最終的にActiveになります。また、エイリアスターゲットとして、CloudFrontのエイリアスターゲットが発行されます。これを対象ドメインのホストゾーンにて、auth.dev.example.com. alias 1234567890.cloudfront.net.といったAliasレコードを登録します。（※1234567890はダミー値）

Name	Type	Value
auth.dev.example.com.	A(※Alias)	1234567890.cloudfront.net.

Cognitoドメインの設定は以上です。

3. 外部IdP（OIDC）側を設定する

今回は説明を割愛します。
外部IdP（OIDC）として使用する Okta の設定は以下エントリの「4.Okta(OIDC)を設定する」を参照ください。

Cognito ユーザープール + ALB の認証に Okta で OpenID Connect (OIDC) 連携を追加してみた | Developers.IO

4. 残りのCognito側を設定する

残りは以下セクションを設定します。

• IDプロバイダー
• 属性マッピング
• アプリクライアントの設定

IDプロバイダーには、外部IdP設定時に発行された クライアントID クライアントシークレット 発行者（Issuer）を入力します。承認スコープは各IdPの要件によりますが、少なくともOIDCとフェデレーションをする上で必要なopenidとemail を入力します。発行者の宛先があっているかどうかは「検出の実行」で検証できます。

問題なければ、プロバイダーの作成を実行します。

次に属性マッピングですが、対象のプロバイダーを選択します。subはデフォルトされているのでそのままにし、今回はOIDC側のemailをCognito側のEmailに入れるように設定します。他、必要に応じて取得したいクレーム（情報）がある場合は、ここで設定します。

最後にアプリクライアントの設定です。　　

まず有効なIDプロバイダを選びますが、Cognitoユーザープール単独のサインイン/サインアップも受け付ける場合はCognito User Poolをチェックし、外部IdPのフェデレーションを行いたい場合は今回でいうOktaをチェックします。

コールバックURLとサインアウトURLは、今回はローカル環境のSPAアプリで検証を想定しているので、http://localhost:3000などのURLを入力します。これをデプロイ済みの開発環境であればhttps://dev.example.com/oauth2/idpresponse、本番環境の場合はhttps://example.com/oauth2/idpresponseなどのように、サービスのドメインにoauth2/idpresponseを末尾につけたURLをOAuth2.0のお作法として使用されます。

OAuth2.0のフローについては、今回は一般的で安全性の高いAuthroization code grantを選択します。
許可されている OAuth スコープでは、emailとopenidを選択します。

これで終了です!

終わりに

以上が、SPAを想定した Cognito と外部IdP（OIDC）の設定手順となります。お役に立てれば幸いです。

それではこの辺で。ちゃだいんでした。